Method for receiving a broadcast signal and broadcast receiver

ABSTRACT

A method of receiving a broadcast signal including a Non-Real-Time (NRT) service and a broadcast receiver are disclosed herein. A method of receiving a broadcast signal including an NRT service, method comprises receiving a broadcast signal including first signaling information and second signaling information, identifying the NRT service based on the first signaling information, identifying an Internet Protocol (IP) address of an NRT service signaling data based on the first signaling information and the second signaling information, receiving the NRT service signaling data by accessing the IP address, and downloading a desired NRT service based on the NRT service signaling data.

This application is a continuation of U.S. application Ser. No.14/051,944 filed Oct. 11, 2013, which is a continuation of U.S.application Ser. No. 13/591,829 filed Aug. 22, 2012, which is acontinuation of U.S. application Ser. No. 12/591,416 filed Nov. 18,2009, and claims the benefit of U.S. Provisional Application No.61/115,888, filed on Nov. 18, 2008, which is hereby incorporated byreference. This application also claims the benefit of U.S. ProvisionalApplication No. 61/121,178, filed on Dec. 9, 2008, which is herebyincorporated by reference. This application also claims the benefit ofU.S. Provisional Application No. 61/138,494, filed on Dec. 17, 2008,which is hereby incorporated by reference. This application also claimsthe benefit of U.S. Provisional Application No. 61/153,973, filed onFeb. 20, 2009, which is hereby incorporated by reference. Thisapplication also claims the benefit of U.S. Provisional Application No.61/153,985, filed on Feb. 20, 2009, which is hereby incorporated byreference. This application also claims the benefit of U.S. ProvisionalApplication No. 61/169,711, filed on Apr. 15, 2009, which is herebyincorporated by reference. This application also claims the benefit ofU.S. Provisional Application No. 61/179,005, filed on May 17, 2009,which is hereby incorporated by reference. And this application alsoclaims the benefit of U.S. Provisional Application No. 61/179,343, filedon May 18, 2009, which is hereby incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a signaling method for a servicetransmitted by Non-Real-Time (hereinafter abbreviated NRT). The detailedinformation on the service through a terrestrial broadcast network andan operation of an NRT receiver for receiving to process thecorresponding information and more particularly, to a broadcast receiverand a method of receiving a broadcast signal including an NRT service.

2. Discussion of the Related Art

A Non-Real-Time (NRT) service is one of the most powerful applicationsthat will be utilized for future Digital Television (DTV) services. TheNRT is accompanied by a non-real-time transmission (not real-timestreaming), storage, and viewing operations. The NRT transmits a contentof a file type on a surplus bandwidth via a broadcast medium such asterrestrial and the like. And, it is expected that the NRT will beimplemented in various kinds of service functions including push VOD,targeted advertising and the like.

SUMMARY OF THE INVENTION

Accordingly, the present invention is directed to a method of receivinga broadcast signal in a broadcast receiver that substantially obviatesone or more problems due to limitations and disadvantages of the relatedart.

An object of the present invention is to provide a method of receiving abroadcast signaling including a Non-Real-Time (NRT) service, whereinreceiving a broadcast signal including first signaling information andsecond signaling information, identifying the NRT service based on thefirst signaling information, identifying an IP address of an NRT servicesignaling data based on the first signaling information and the secondsignaling information, receiving the NRT service signaling data byaccessing the IP address, and downloading a desired NRT service based onthe NRT service signaling data.

Another object of the present invention is to provide a broadcastreceiver for receiving a broadcast signal including a Non-Real-Time(NRT) service, wherein a first receiving unit for receiving first signalinformation and second signaling information, a first handler foridentifying the NRT service based on the first signaling information, asecond handler for identifying an IP address of an NRT service signalingdata based on the first signaling information and the second signalinginformation, a second receiving unit for receiving the NRT servicesignaling data by accessing the IP address, and a controller fordownloading a desired NRT service based on the NRT service signalingdata.

Additional advantages, objects, and features of the invention will beset forth in part in the description which follows and in part willbecome apparent to those having ordinary skill in the art uponexamination of the following or may be learned from practice of theinvention. The objectives and other advantages of the invention may berealized and attained by the structure particularly pointed out in thewritten description and claims hereof as well as the appended drawings.

It is to be understood that both the foregoing general description andthe following detailed description of the present invention areexemplary and explanatory and are intended to provide furtherexplanation of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this application, illustrate embodiment(s) of the invention andtogether with the description serve to explain the principle of theinvention. In the drawings;

FIG. 1 is an exemplary conceptional diagram of an NRT service;

FIG. 2 is a block diagram of a receiving system according to anembodiment of the present invention;

FIG. 3 is an exemplary diagram explaining relations between an NRTservice, content items and files;

FIG. 4 is a diagram for a protocol stack of a fixed NRT serviceconfigured according to an embodiment of the present invention;

FIG. 5 is an exemplary diagram of an Advanced Television SystemsCommittee (ATSC) service type according to the present invention;

FIG. 6 is an another exemplary diagram of an ATSC service type accordingto the present invention;

FIG. 7 is a diagram for a bit-stream section of a Terrestrial VirtualChannel Table (TVCT) section configured according to an embodiment ofthe present invention;

FIG. 8 is a diagram for a bit-stream syntax of a Data Service Table(DST) section to identify an NRT application configured according to anembodiment of the present invention;

FIG. 9 is a diagram for a signaling method in case of transmitting anNRT service through an ATSC broadcasting system according to anembodiment of the present invention;

FIG. 10 is a flowchart for FIG. 9.

FIGS. 11 and 12 are a diagram for a bit-stream syntax of Non-Real-TimeService Table (NST) extracted by a receiver from a received MPEG-2 TSconfigured according to an embodiment of the present invention;

FIG. 13 is a diagram for a bit-stream syntax ofNRT_component_descriptor( ) configured according to an embodiment of thepresent invention;

FIG. 14 is a diagram for a bit-stream syntax ofNRT_component_data_descriptor for File Delivery over UnidirectionalTransport (FLUTE) file delivery configured according to an embodiment ofthe present invention;

FIGS. 15 and 15B are a diagram for a bit-stream syntax of anNon-Real-Time Content Table (NCT) section configured according to anembodiment of the present invention;

FIG. 16 is a flowchart for a method of configuring NRT guide informationand providing contents according to another embodiment of the presentinvention;

FIG. 17 is a diagram for an NRT service signaling structure configuredaccording to another embodiment of the present invention;

FIG. 18 is a diagram to explain a FDT schema for mapping a file tocontent_id according to an embodiment of the present invention;

FIG. 19 is a diagram to explain a FDT schema for mapping a file tocontent_id according to another embodiment of the present invention; and

FIG. 20 is a flowchart to explain a process for processing an NRTservice in a receiver according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

Reference will now be made in detail to the preferred embodiments of thepresent invention, examples of which are illustrated in the accompanyingdrawings. Wherever possible, the same reference numbers will be usedthroughout the drawings to refer to the same or like parts.

Terminologies used for the present invention are selected from generalterminologies, which are currently and widely used, in consideration ofthe functions in the present invention but may vary according tointentions of a person having an ordinary knowledge in the technicalfield, practices or the advent of new technology, etc. In specific case,a terminology may be arbitrarily chosen by the applicant(s). In suchcase, its detailed meaning shall be described in the DetailedDescription of the Invention. Therefore, the terminology used for thepresent invention needs to be defined based on the intrinsic meaning ofthe terminology and the contents across the present invention instead ofa simple name of the terminology.

FIG. 1. is an exemplary conceptional diagram of an NRT service.

A broadcasting station transmits a real-time (hereinafter abbreviatedRT) service according to a conventional method. In doing so, thebroadcasting station transmits the RT service or the Non-Real-Time (NRT)service using a bandwidth left in the due course. In such case, the NRTservice can contain a movie, news clip, weather information,advertisements, and contents for Push Video on Demand (VOD), and thelike.

A legacy device has the principle that the operation is not affected byan NRT stream included within a channel. However, a DTV receiver, arelated art, has a problem in receiving and processing the NRT serviceprovided by a broadcasting station properly because of not having ameans for processing unit for the NRT service.

On the contrary, a broadcast receiver according to the presentinvention, i.e., an NRT device is able to properly receive and processan NRT service combined with an RT service, thereby providing a viewerwith more various functions than those of the related art DTV.

In this case, the RT service and the NRT service are transmitted on thesame DTV channel or different DTV channels and are transmitted throughan MPEG-2 transport packet (TP) or an internet protocol (IP) datagram.Hence, a receiver needs to identify the two kinds of servicestransmitted on the same or different channel. A method of defining andproviding signaling information to enable a receiver to receive andprocess an NRT service is described. The broadcasting station providessignaling information of at least one unique packet identifier (PID) foridentifying an NRT service.

FIG. 2 is a block diagram of a receiving system according to anembodiment of the present invention.

Referring to FIG. 2, the receiving system mainly includes a basebandprocessor, an MPEG-2 service demultiplexer (demux), a stream componenthandler, a media handler, a file handler, and other parts. The units ofthe receiving system shown in FIG. 2 are explained in the following.

First of all, the baseband processor includes a tuner 201 and avestigial side band (VSB) demodulator 202. The tuner 201 detects VSBradio frequency (RF) signal transmitted over the air and then extracts asymbol from the detected VSB RF signal. In this case, the tuner 201 iscontrolled by a service manager 228. The VSB demodulator 202reconstructs meaningful data by demodulating the VSB symbol extracted bythe tuner 201.

The MPEG-2 service demultiplexer includes an MPEG-2 TP buffer/parser203, a program specific information/program and system informationprotocol (PSI/PSIP) section/buffer 204, a descrambler 205, an MPEG-2 TPdemultiplexer (demux) 206 and a personal video recorder (PVR) storage207.

The MPEG-2 TP buffer/parser 203 buffers and reconstructs the MPEG-2 TPcarried on a VSB signal and then detects and processes a TP header.

The PSI/PSIP section/buffer 204 buffers and parses PSI/PSIP section datacarried on an MPEG-2 TS. In this case, the parsed PSI/PSIP data (ProgramMap Table (PMT), Terrestrial Virtual Channel Table (TVCT), and DataService Table (DST)) is collected by the service manager 228 and is thenstored as a service map and guide data in a database. The NRT service isidentified using the parsed PSI/PSIP data (PMT, TVCT, and DST).

The descrambler 205 reconstructs data of a payload for a scrambledpacket payload in the MPEG-2 TP, using an encryption key or the like,delivered from a conditional access (CA) stream handler 216.

The MPEG-2 TP demultiplexer 206 filters an MPEG-2 TP varied on a VSBsignal or a TP depending on the receiver that is to process among theMPEG-2 TP stored in the PVR storage 207 and then relays the filtered TPto a proper processing module. In this case, the MPEG-2 TP demultiplexer206 can be controlled by the service manager 228 and the PVR manager235.

The PVR storage 207 stores the received MPEG-2 TP using the VSB signalwhen requested by the end-user and outputs the MPEG-2 TP when requestedby the end-user. In this case, the PVR storage 207 can be controlled bythe PVR manager 235.

The stream component handler includes a packetized elementary stream(PES) buffer/handler 208, an elementary stream (ES) buffer/handler 209,a program clock reference (PCR) handler 210, a system time clock (STC)unit 211, a digital storage media command and control (DSM-CC) sectionbuffer/handler 212 which receives the NRT Service Table (NST), an IPdatagram buffer/header parser 213, an end-user datagram protocol (UDP)datagram buffer/handler 215, a CA stream buffer/handler 216 and aservice signaling section buffer/handler 217.

The PES buffer/handler 208 buffers and reconstructs a PES carried on anMPEG-2 TS.

The ES buffer/handler 209 buffers and reconstructs an ES such as audiodata, video data or the like, which is transmitted as a PES, and thendelivers the reconstructed ES to a proper A/V decoder 218.

The PCR handler 210 handles PCR data used for time synchronization ofaudio and video streams or the like.

The STC unit 211 corrects a clock value of the A/V decoder 218 using areference clock value delivered via the PCR handler 210 to enable timesynchronization.

The DSM-CC section buffer/handler 212 buffers and handles DSM-CC sectiondata for a file transmission via the MPEG-2 TP and an IP datagramencapsulation. An actual IP level transmission is carried out in awell-known IP address, such that the receiver can receive an IP levelwithout separately acquiring IP connection information.

The IP datagram buffer/header parser 213 buffers and reconstructs an IPdatagram, which is encapsulated via DSM-CC addressable section and isthen carried on an MPEG-2 TP. The IP datagram buffer/header parser 213parses a header of each IP datagram through the reconstruction. In thiscase, the IP datagram buffer/header parser 213 is controlled by theservice manager 228. The IP datagram buffer 213, the UDP datagram buffer215, and the service signaling section parser 217 receives and processesthe NRT Content Table (NCT) and NRT Service Table (NST) from the ATSC8-VSB signal. The NCT and NST are transmitted through well-known IPaddress number and UDP port number.

If scrambling is applied to a payload in the received IP datagram, thedescrambler 214 reconstructs data of the payload using an encryption keyfor the payload delivered from the CA stream handler 216.

The UDP datagram buffer/handler 215 buffers and reconstructs a UDPdatagram carried on an IP datagram and also parses and processes a UDPheader.

The CA stream buffer/handler 216 buffers and handles such data as a keyvalue for descrambling, for example, an entitlement management message(EMM) transmitted for a conditional access function carried on an MPEG-2TS or an IP stream, an entitlement control message (ECM). In this case,an output of the CA stream buffer/handler 216 is delivered to thedescrambler 214 to perform a decryption operation of an MPEG-2 TP or anIP datagram that carries AV data, file data and the like.

The service signaling section buffer/parser 217 processes a signalinginformation like an NRT Service Table (NST), an NRT Content Table (NCT)and descriptors related to the NST or the NCT for signaling an NRTservice of the present invention. The processed signaling information istransferred to the NRT service manager 229.

The media handler includes A/V decoders 218.

The AV decoders 218 decode compressions of audio and video datadelivered via the ES handler 209 and then processes the decoded data,which are to be presented to an end-user.

The file handler includes an Asynchronous Layered Coding/Layered CodingTransport (ALC/CLT) buffer/parser 219, a file description table (FDT)handler 220, an extensible markup language (XML) parser 221, a filereconstruction buffer 222 and a decompressor 223.

The ALC/LCT buffer/parser 219 buffers and reconstructs ALC/LCT datacarried on UDP/IP stream and then parses a header of ALC/LCT and aheader extension thereof. In this case, the ALC/LCT buffer/parser 219can be controlled by the NRT service manager 229.

The FDT handler 220 parses and processes a FDT of a File Delivery overUnidirectional Transport (FLUTE) protocol transmitted via an ALC/LCTsession. It is able to transfer the processed FDT to the NRT servicemanager 229. The FDT handler 220 can also be controlled by the NRTservice manager 229.

The XML parser 221 parses an XML document transmitted via the ALC/LCTsession and then delivers the parsed data to such a proper module as theFDT handler 220, the SG handler 227 and the like.

The file reconstruction buffer 222 reconstructs a file transferred tothe ALC/LCT and FLUTE session.

If the file transferred to the ALC/LCT and FLUTE session is compressed,the decompressor 223 performs a process for decompressing thecompression.

The file decoder 224 decodes a file reconstructed by the filereconstruction buffer, a file decompressed by the decompressor 223, or afile extracted from the file storage 225.

The file storage 225 stores and extracts the received file. In thiscase, the received file may contain NRT content.

Finally, the remaining parts, not explained above, will be explained asfollows.

A middleware (M/W) engine 226 processes data of a file that is not an AVstream transferred via a DSM-CC section or an IP diagram, and thendelivers the processed data to the presentation manager 234.

The SG handler 227 collects and parses service guide data transferred inan XML document format and then delivers the parsed data to the EPGmanager 230.

The service manager 228 produces a service map by collecting and parsingthe PSI/PSIP data carried on MPEG-2 TS and service signaling sectiondata carried on an IP stream and then controls an access to a servicespecified by an end-user by storing the service map in a service map &guide database. In this case, the service manager 228 is controlled byan operation controller 230 and then controls the tuner 201, the MPEG-2TP demultiplexer 206, the IP datagram buffer/handler 213, and the NRTservice manager 229.

The NRT service manager 229 performs overall managements on the NRTservice transferred in an object/file format via FLUTE session on an IPlayer. The NRT service manager 229 parses the signaling informationtransferred from the service signaling section buffer/parser 217. And,the parsed signaling information is transferred to the service map &guide database 236 to be stored therein. Moreover, the NRT servicemanager 229 controls NCT information, which correspond to contentsrelated to a service guide in the signaling information, to betransferred to the EPG manager 230, thereby forming EPG data. In thiscase, the NRT service manager 229 controls the FDT handler 220, the filestorage 225 and the like. Therefore, the NRT service manager 229receives the FDT from the FDT handler 220, parses the received FDT andthen controls received NRT contents to be stored as a hierarchicalstructure in the file storage 225. And, the NRT service manager 229controls the corresponding NRT contents to be extracted from the filestorage 225 in case that a user makes a selection for the NRT service.The service map & guide database 236 may further store informationcontaining future download time and contents, including files associatedwith the contents, inputted by the end-user through UI Manager 232.Following such an input from the end-user, when the download time hasbeen reached, the service map & guide database will start downloadingthe contents through operation controller 233, EPG manager and storesthe content.

The EPG manager 230 receives the service guide data from the SG handler227, configures EPG data, and then controls the EPG data to bedisplayed. The EPG manager 230 will configure the service guideinformation and UI manager 232 will display the NRT service guide toend-user based on the defined NCT fields. Therefore, the title,available time for download, and the estimated download time aredisplayed so the end-user can choose the content or the files associatedwith the content that the end-user wishes to download.

The application manager 231 performs overall managements on processingof application data transferred in such a format as an object, a fileand the like.

The user interface (UI) manager 232 delivers an input of a user via a UIto the operation controller 233 and enables an operation of a processfor a user-requested service to be initiated.

The operation controller 233 processes a user's command delivered viathe UI manager 232 and then enables a manager of a necessary module toperform a corresponding action.

And, the presentation manager 234 provides at least one of A/V dataoutputted from the A/V decoder 218, file data outputted the middleware(M/W) engine 226 and EPG data outputted from the EPG manager 230 to uservia speaker and/or screen.

FIG. 3 is an exemplary diagram explaining relations between an NRTservice, content items and files.

Referring to FIG. 3, an NRT service can include one or more contentitems. And, each of the content items can include one or more files.And, each of the content items is an independent entity and maycorrespond to a program or an event in a real time broadcast. Therefore,the NRT service can be defined as a group that is able to service incombination of the above content items.

In order for a receiver to properly process the above NRT service,signaling for the corresponding NRT service is required. The presentinvention intends to properly process an NRT service received by areceiver by defining and providing the signaling information. Thedetails of the signaling information shall be described in thedescription of the corresponding part.

NRT services can be mainly categorized into a fixed NRT service and amobile NRT service. In the following description, the fixed NRT serviceis taken as an example for an embodiment of the present invention. Asshown in FIG. 3, an NRT service may include one or more contents and thecontents can have one or more files associated with the contents.

FIG. 4 is a diagram for a protocol stack of a fixed NRT serviceconfigured according to an embodiment of the present invention.

Referring to FIG. 4, a protocol stack for providing a fixed NRT servicetransmitting NRT content items and/or files is illustrated. The IPdatagram includes NRT content items and/or files and signaling channelfor providing NST and NCT. Program and System Information/Program andSystem Information Protocol (PSI/PSIP) data is delivered through anMPEG-2 TS format.

In FIG. 4, the fixed NRT service is packetized according to UserDatagram Protocol (UDP) in an IP layer. The UDP packet becomes UDP/IPpacket data by being packetized again according to an IP scheme. In thisdisclosure, the packetized UDP/IP packet data is referred to as an IPdatagram.

The NRT content items/files are packetized according to File Deliveryover Unidirectional Transport (FLUTE) scheme or Asynchronous LayeredCoding/Layered Coding Transport (ALC/LCT) scheme. The ALC/LCT packet istransported by being encapsulated in a UDP datagram. The ALC/LCT/UDPpacket is packetized into ALC/LCT/UDP/IP packet according to IP datagramscheme to become an IP datagram. This IP datagram is contained in MPEG-2TS through DSM-CC addressable sections for transport. In this case, theALC/LCT/UDP/IP packet is the information on FLUTE session and includes aFile Delivery Table (FDT) as well.

A signaling information channel including an NST and an NCT ispacketized according to a UDP scheme. This UDP packet is packetizedaccording to an IP scheme again to become UDP/IP packet data, IPdatagram. This IP datagram is also contained in the MPEG-2 TS throughthe DSM-CC addressable sections for transport.

And, a PSI/PSIP table is separately defined and contained in the MPEG-2TS. The PSI/PSIP data includes signaling information (PMT, TVCT, andDST) for identifying an NRT.

The MPEG-2 TS containing the above described NRT content items/files,signaling information channel and PSI/PSIP data therein are transferredby being modulated by a predetermined transmission scheme such as VSBtransmission scheme.

According to the present invention, a fixed NRT service uses aconventional ATSC terrestrial broadcasting environment. In particular, afixed NRT service, which is based on a scheme of transporting an IPdatagram via DSM-CC addressable section, can be provided by thefollowing method for example.

1. Case of transmission on virtual channel including audio and/or video:

In this case, a service type of a corresponding virtual channel canfollow FIG. 5 as stipulated in the conventional ATSC specification. Thisservice type is a field defined in the TVCT of FIG. 7. In particular,the service type follows ‘0x04’ indicating ATSC data only service shownin FIG. 5 which shows the NRT service category and its meanings.Alternatively, the service type can identify an NRT service by beingincluded in another service type of the related art.

2. Case of transmission on virtual channel including NRT service only:

Referring to FIG. 6, a NRT service category and its meanings, signalingcan be performed to indicate an NRT application (‘0x08’) by allocating anew service type value. This service type is a field defined in the TVCTof FIG. 7.

FIG. 7 is a diagram for a bit-stream section of a Terrestrial VirtualChannel Table (TVCT) section configured according to an embodiment ofthe present invention.

Referring to FIG. 7, a Terrestrial Virtual Channel Table (TVCT) sectionis described as having a table format similar to that of an MPEG-2private section. However, this is merely exemplary, and the presentinvention will not be limited to the example given herein.

The TVCT can be divided into a header, a body and a trailer. The headerpart ranges from table_id field to protocol_version field. And,transport_stream_id field is a 16-bit field and indicates an MPEG-2 TSIDwithin a Program Association Table (PAT) defined by a PID value of ‘0’for multiplexing. In the body part, num_channels_in_section field is an8-bit field and indicates the number of virtual channels within a VCTsection. Finally, the trailer part includes CRC_(—)32 field.

First of all, the header part is explained as follows.

A table_id field is an 8-bit unsigned integer number that indicates thetype of table section being defined herein. For theterrestrial_virtual_channel_table_sectionQ, the table_id shall be‘0xC8’.

A section_syntax_indicator is a one-bit field which shall be set to ‘1’for the terrestrial_virtual_channel_table_section( ).

A private_indicator field (1-bit) shall be set to ‘1’.

A section_length is a twelve bit field, the first two bits of whichshall be ‘00’. This field specifies the number of bytes of the section,starting immediately following the section_length field, and includingthe CRC. The value in this field shall not exceed 1021.

A table_id_extension field is set to ‘0x000’.

A version_number field (5-bit) represents the version number of the VCT.

A current_next_indicator is a one-bit indicator, which when set to ‘1’indicates that the VCT sent is currently applicable.

A section_number field (8 bit) gives the number of this section. Thesection_number of the first section in the TVCT shall be ‘0x00’.

A last_section_number field (8 bit) specifies the number of the lastsection (that is, the section with the highest section_number) of thecomplete TVCT.

A protocol_version is an 8-bit unsigned integer field whose function isto allow, in the future, this table type to carry parameters that may bestructured differently than those defined in the current protocol. Atpresent, the only valid value for protocol_version is zero. Non-zerovalues of protocol_version may be used by a future version of thisstandard to indicate structurally different tables.

The body part is explained as follows.

A num_channels_in_section field (8-bit) specifies the number of virtualchannels in this VCT section. The number is limited by the sectionlength.

A short_name field represents the name of the virtual channel,represented as a sequence of one to seven 16-bit code values.

A major_channel_number field is a 10-bit number that represents the“major” channel number associated with the virtual channel being definedin this iteration of the “for” loop. Each virtual channel shall beassociated with a major and a minor channel number. The major channelnumber, along with the minor channel number, act as the user's referencenumber for the virtual channel.

A minor_channel_number field is a 10-bit number in the range ‘0’ to‘999’ that represents the “minor” or “sub”-channel number. This field,together with major_channel_number, performs as a two-part channelnumber, where minor_channel_number represents the second or right-handpart of the number. When the service_type is analog television,minor_channel_number shall be set to ‘0’. Services whose service_type iseither ATSC_digital_television or ATSC_audio_only shall use minornumbers between ‘1’ and ‘99’. The value of minor_channel_number shall beset such that in no case is a major_channel_number/minor_channel_numberpair duplicated within the TVCT.

A modulation_mode field is an 8-bit unsigned integer number thatindicates the modulation mode for the transmitted carrier associatedwith this virtual channel.

A carrier_frequency field includes the recommended value for these 32bits is zero. Use of this field to identify carrier frequency isallowed, but is deprecated.

A channel_TSID is a 16-bit unsigned integer field in the range ‘0x0000’to ‘0xFFFF’ that represents the MPEG-2 TSID associated with the TScarrying the MPEG-2 program referenced by this virtual channel.

A program_number field is a 16-bit unsigned integer number thatassociates the virtual channel being defined here with the MPEG-2PROGRAM ASSOCIATION and TS PROGRAM MAP tables. For virtual channelsrepresenting analog services, a value of ‘0xFFFF’ shall be specified forprogram_number.

An ETM_location is 2-bit field specifies the existence and the locationof an Extended Text Message (ETM).

An access_controlled is a 1-bit Boolean flag that indicates, when set,that the events associated with this virtual channel may be accesscontrolled. When the flag is set to ‘0’, event access is not restricted.

A hidden is a 1-bit Boolean flag that indicates, when set, that thevirtual channel is not accessed by the user by direct entry of thevirtual channel number. Hidden virtual channels are skipped when theuser is channel surfing, and appear as if undefined, if accessed bydirect channel entry. Typical applications for hidden channels are testsignals and NVOD services. Whether a hidden channel and its events mayappear in EPG displays depends on the state of the hide_guide bit.

A hide_guide is a Boolean flag that indicates, when set to ‘0’ for ahidden channel that the virtual channel and its events may appear in EPGdisplays. This bit shall be ignored for channels which do not have thehidden bit set, so that non-hidden channels and their events may alwaysbe included in EPG displays regardless of the state of the hide_guidebit. Typical applications for hidden channels with the hide_guide bitset to ‘1’ are test signals and services accessible throughapplication-level pointers.

A service_type is a 6-bit enumerated type field that shall identify thetype of service carried in this virtual channel.

A source_id field (16-bit) represents a programming source associatedwith a virtual channel.

A descriptors_length field is total length (in bytes) of the descriptorsfor this virtual channel that follows.

A descriptor( ) field includes zero or more descriptors, as appropriate,may be included.

An additional_descriptors_length field is total length (in bytes) of theVCT descriptor list that follows.

The trailor part is explained as follows. CRC_(—)32 is a 32-bit fieldthat contains the cyclic redundancy check (CRC) value that ensures azero output from the registers in the decoder.

NRT content is transferred through IP mechanism. In order to transfer IPdatagram through a digital broadcast stream, ATSC has regulated ATSCA/90 and A/92 specifications.

In the above description, the data service table (DST) may be receivedthrough a PID included in service_location_descriptor. And, it is ableto know a type of application and detailed information of a databroadcast stream carried on this channel through the DST.

According to FIG. 8, it is able to use a DST to identify an NRT service.The DST is explained as follows.

FIG. 8 is a diagram for a bit-stream syntax of a DST section to identityan NRT application configured according to an embodiment of the presentinvention.

The semantics of the fields comprising the data_service_table_bytesstructure are defined below.

An sdf_protocol_version is an 8-bit field which shall be used to specifythe version of the Service Description Framework (SDF) protocol. Thevalue of this field shall be set to ‘0x01’. The value ‘0x00’ and thevalues in the range ‘0x02’ to ‘0xFF’ shall be ATSC reserved.

An application_count_in_section is an 8-bit field (8-bit) shall specifythe number of applications listed in the DST section.

A compatibility_descriptor( ) field shall contain a DSM-CC compatibilitydescriptor. Its purpose shall be to signal compatibility requirements ofthe application so that the receiving platform can determine its abilityto use this data service.

An app_id_byte_length field (16-bit) shall specify the number of bytesused to identify the application. The value of this field shall accountfor the length of both the app_id_description field and the app_id_bytefields that follow. The value ‘0x0000’ shall indicate that noapp_id_description field or app_id_byte fields follow. The value‘0x0001’ is forbidden.

An app_id_description field (16-bit) shall specify the format andsemantics of the following application identification bytes.

Table 1 specifies the values and associated formats.

TABLE 1 Value Application Identifier Format 0x0000 DASE application0x0001 ATSC reserved 0x0002 ATSC A/92 Application 0x0003 NRT Application0x0004-0x7FFF ATSC reserved 0x8000-0xFFFF User private

An app_id_byte field (8-bit) shall represent a byte of the applicationidentifier.

A tap_count field (8-bit) shall specify the number of Tap( ) structuresused by this application.

A protocol_encapsulation field (8-bit) shall specify the type ofprotocol encapsulation used to transmit the particular data elementreferred to by the Tap( ).

TABLE 2 Value Encapsulated Protocol 0x00 Not in a MPEG-2 TransportStream 0x01 Asynchronous non-flow controlled scenario of the DSM-CCDownload protocol encapsulated in DSM-CC sections 0x02 Non-streamingSynchronized Download protocol encapsulated in DSM-CC sections 0x03Asynchronous multiprotocol datagrams in Addressable Sections usingLLC/SNAP header 0x04 Asynchronous IP datagrams in Addressable Sections0x05 Synchronized streaming data encapsulated in PES 0x06 Synchronousstreaming data encapsulated in PES 0x07 Synchronized streamingmultiprotocol datagrams in PES using LLC/SNAP header 0x08 Synchronousstreaming multiprotocol datagrams in PES using LLC/SNAP header 0x09Synchronized streaming IP datagrams in PES 0x0A Synchronous streaming IPdatagrams in PES 0x0B Proprietary Data Piping 0x0C SCTE DVS 051asynchronous protocol [19] 0x0D Asynchronous carousel scenario of theDSM-CC Download protocol encapsulated in DSM-CC sections 0x0E Reservedfor harmonization with another standard body 0x0F-0x7F ATSC reserved0x80-0Xff User defined

An action_type field (7-bit) shall be used to indicate the nature of thedata referred to by the Tap( ).

A resource_location field (1-bit) shall specify the location of theAssociation Tag field matched with the association_tag value listed inthe following Tap structure. This bit shall be set to ‘0’ when thematching association_tag resides in the PMT of the current MPEG-2program. This bit shall be set to ‘1’ when the matching association_tagresides in a DSM-CC Resource Descriptor within the Network ResourcesTable of this Data Service.

A tap_id field (16-bit) shall be used by the application to identify thedata elements. The value of tap_id is scoped by the value of theapp_id_byte fields associated with the Tap( ) in the DST. The tap_idfield is unique within an application. The tap_id value is selected bythe data service provider at authoring time. It is used in theapplication as a handle to the data element.

A use field (16-bit) is used to characterize the communication channelreferenced by the association_tag. Use of use values other than ‘0x0000’is beyond the scope of this standard. The use value ‘0x0000’ indicatesthat this field is unknown.

An association_tag field (16-bit) shall uniquely identify either a dataelementary stream listed in the PMT or a DSM-CC Resource Descriptorlisted in the Network Resource Table. In the former case, the value ofthis field shall be matched with the association_tag value of anassociation_tag_descriptor in the PMT of the data service. In the lattercase, the value of this field shall match the association_tag value inthe commonDescriptorHeader structure of a DSM-CC Resource Descriptor inthe Network Resource Table of the data service.

A selector_length is an 8-bit field which shall specify the length ofthe remaining selector structure in bytes. A value equal to 0 shallindicate that no selector information is present. When the value of theselector_type field is equal to 0x0102, this field shall be set to avalue less or equal to 8.

A tap_info_length is a 16-bit field which shall specify the number ofbytes of the descriptors following the tap_info_length field.

A descriptor_tag is a 8-bit field which shall be set to 0xA6.

A descriptor_length is a 8-bit field which shall specify the length inbytes of the fields immediately following this field up to the end ofthis descriptor.

A deviceId_address_range is a 3-bit field which shall indicate thenumber of valid deviceId address bytes that the service uses.

A deviceId_IP_mapping_flag is a 1-bit field which shall be set to “1” tosignal an IP to MAC address mapping. This flag shall be set to “0” forany other device ID address mapping.

An alignment_indicator is a 1-bit field which shall be set to 0 toindicate byte level alignment between the DSMCC_addressable_section andthe Transport Stream bytes.

A max_sections_per_datagram is a 8-bit field which shall indicate themaximum number of Sections that can be used to carry a single datagramunit.

An app_data_length field (16-bit) shall specify the length in bytes ofthe following app_data_byte fields.

An app_data_byte field (8-bit) shall represent one byte of the inputparameters and other private data fields associated with theapplication.

An app_info_length is an 8-bit field which shall specify the number ofbytes of the descriptors following the app_info_length field.

A descriptor( ) shall follow the descriptor format.

A service_info_length (8-bit) shall specify the number of bytes of thedescriptors following the service_info_length field.

Another descriptor( ) field shall follow the descriptor format.

A service_private_data_length field (16-bit) shall specify the length inbytes of the private fields to follow.

A service_private_data_byte field (8-bit) shall represent one byte ofthe private field.

After the NRT application has been identified, a PID for detecting an IPstream and an IP information on which a well-known IP address fordelivering NRT service signaling data delivered via an IP layer, aresearched for using tap information and multiprotocol encapsulationdescriptor.

If a value of protocol_encapsulation is set to ‘0x04’, an asynchronousIP datagram is transferred. If selector_type is set to ‘0x0102’, a valueof device_id, which indicates a destination address, is deliveredthrough selector_bytes. In order to accurately interpret a value of theselector_bytes, multiprotocol_encapsulation_descriptor is used. And, thenumber of valid bytes in the device_id value is signaled.

Therefore, it is able to know a multicast address (or, an address range)of an IP datagram carried on the corresponding PID via the tapinformation.

Through the Tap, it is checked as to which IP stream will be deliveredthrough the PID. And this is received in the first place. An IP packetis then received.

The NRT service signaling data is extracted from the IP packet. Theextracted NRT service signaling data is delivered to and processed by aService Signaling Section Buffer/Parser. An NRT service can be theninitiated.

FIG. 9 is an exemplary diagram for a signaling method in case oftransmitting an NRT service through an ATSC broadcasting systemaccording to another embodiment of the present invention, and FIG. 10 isan exemplary flowchart for FIG. 9.

FIG. 9 shows a method of configuring a separate NRT service signalingchannel via an IP side. In this case, the NRT service signaling channelis multicasted by being encapsulated in an IP datagram via a well-knownIP address. A signaling structure for this case is shown in FIG. 9. Inparticular, it can be observed that a separate NRT service signalingchannel exists as an IP multicast stream, whereas every signaling isperformed by a PSIP side.

The TVCT is similar to a channel concept and for example, the TVCT_PIDequals to ‘0x1FFB.’ The service_type of TVCT refers to the service ofthe present TVCT which identifies that the service is an NRT applicationand the stream_type which equals to for example ‘0x95’ means that it isassociation with the Data Service Table (DST). The app_id_descriptionfield in the DST also identifies that the service is an NRT application.As shown in FIG. 9, the association_tag of the PMT has the same valuewith the Tap association_tag in the DST. After matching the associationtag between the PMT and the DST, the elemenrayr_PID of the PMT is neededto identify the IP datagram of the NRT service signaling channel or theNRT service. As explained above, when the protocol_encapsulation=0x04,an asynchronous IP datagram is transferred. If selector_type is set to‘0x0102’, a value of device_id, which indicates a destination address,is delivered through selector_bytes. In order to accurately interpret avalue of the selector_bytes, multiprotocol_encapsulation_descriptor isused. And, the number of valid bytes in the device_id value is signaled.

A Tap( ) in the DST is used to find an application-level data elementcontained in a lower-layer communication channel. An association is madebetween the application-level data element and the Tap( ) through theuse of an association_tag field. The value of the association_tag fieldin a Tap structure shall correspond to the value of either anassociation_tag field located in one Association Tag descriptor residingin the current PMT or an associationTag field located in thecommonDescriptorHeader of one of the dsmccResourceDescriptor descriptorsresiding in the Network Resource Table. In a data service, the sameassociation_tag value may be featured in more than one Tap structure.The association_tag shall be used as the base for determining thelocation of a data element. Relative to this base, the location of thedata element may be further specified by means of the selectorstructure. A data receiver needs a reference list of all synchronizeddata elementary streams in a data service to be able to partition theData Elementary Stream Buffer properly. Consequently, the DST shallinclude at least one Tap( ) for each of the data elementary streams ofstream_type value 0x06 or 0x14 belonging to the data service.

A multiprotocol_encapsulation_descriptor may be included in thedescriptor loop following the Tap structure in the Data Service Tablewhen the value of the protocol_encapsulation field is equal to 0x03 or0x04. The descriptor provides information defining the mapping of thedeviceId fields to a specific addressing scheme. The descriptor alsoprovides information on the number of valid bytes in the devideld fieldsspecified in the selector bytes of a Tap( ) including a selector_typefield value equal to 0x0102. Finally, this descriptor may be used tosignal alignment and protocol fragmentation rules.

A deviceId_address_range=0x06 means that the valid deviceID_addressbytes equal to deviceId[47 . . . 0]. Further deviceId_IP_mapping_flag,when set to 1 means to signal an IP to MAC address mapping.

An alignment_indicator shall indicate byte level alignment between theDSMCC_addressable_section and the Transport Stream bytes.

And max_sections_per_datagram, an 8-bit field, shall indicate themaximum number of Sections that can be used to carry a single datagramunit.

Further, the well-known IP address for NRT service signaling channel(NST and NCT) is defined through elementary_PID associated with the PMT.Moreover, the NRT service signaling data is transmitted and receivedthrough the well-known IP address for NRT service signaling channel ofthe IP Datagram. The NRT service signaling data can be transmitted inTransport Packet (TP) or via Internet Protocol (IP).

FIG. 10 is a flowchart of the above explanation.

Referring to FIG. 10, after a power of a receiver has been turned on, ifa default channel or a channel by a user is selected [S1001], thereceiver receives a TVCT or a PMT [S1002].

With regard to this, information on a stream configuring each virtualchannel is signaled to service_location_descriptor of the TVCT or theES_loop of the PMT.

Therefore, the receiver determines a type of a service provided on aselected channel by parsing service_type within the received TVCT[S1003]. For instance, if a value of the service_type is set to ‘0x02’,a type of a corresponding service provided on the selected channel maymean a digital A/V Data service type. If a value of the service_type isset to ‘0x04’, a type of a corresponding service provided on theselected channel may mean a data only service type. If a value of theservice_type is set to ‘0x08’, a type of a corresponding serviceprovided on the selected channel may mean an NRT only service type.

As a result of the determining step [S1003], if the correspondingservice type is not a general A/V service, PID (‘0x61’) of a dataservice table (DST) is extracted by parsing service_location_descriptorin the channel loop of the TVCT [S1004].

Subsequently, the DST is received using the extracted PID [S1005].

It is then determined whether the corresponding service provided on theselected channel is an NRT service from the received DST [S1006]. Indoing so, the determination of a presence or absence of the NRT servicecan be performed by checking app_id_description within the DST. Forinstance, if a value of the app_id_description is set to ‘0x0003’, itmeans that the corresponding service is an NRT application.

As a result of the determining step [S1006], if the correspondingservice is an NRT service, a tap including an NRT service signalingchannel is extracted [S1007]. And, elementary_PID includingassociation_tag of the tap on the PMT is extracted [S1008].

After the elementary_PID has been received, a DSM-CC addressable sectionis processed [S1009].

Subsequently, after an IP packet has been received from a well-known IPaddress of the NRT service signaling channel [S1010], an NRT service isprovided by processing the NRT service signaling data within thereceived IP packet [S1011].

With regard to this, after checking whether the NRT application existson the virtual channel by the above method, an IP stream carrying thewell-known IP address, to which the NRT service signaling data carriedvia an IP layer is delivered, is searched for using the tap information.

If a value of protocol_encapsulation is set to ‘0x04’, an asynchronousIP datagram is transferred. If selector_type is set to ‘0x0102’, a valueof device_id indicating a destination address is delivered viaselector_bytes.

Therefore, a PID of a transport stream can be known, on which thecorresponding data is carried, through the tap information on amulticast address (or, an address range) of an IP datagram. It ischecked whether a well-known IP address, to which NRT service signalingdata will be delivered, is loaded on the tap. This is received in thefirst place. An IP packet is then received.

Subsequently, NRT service signaling data is extracted from the IPpacket. The extracted NRT service signaling data is delivered to an NRTapplication manager. A corresponding service is then initiated.

FIGS. 11 and 12 are an exemplary diagram for a bit-stream syntax of NSTconfigured according to an embodiment of the present invention.

In this case, although a corresponding syntax is written as an MPEG-2private section to help the understanding, a format of correspondingdata can have any type. For instance, SDP( ) is used to performsignaling via a Session Announcement Protocol (SAP).

NST/NCT describes service information and IP access information within avirtual channel carrying the NST/NCT. The NST/NCT also providesbroadcast stream information of a corresponding service using TSID thatis an identifier of a broadcast stream to which each service belongs.And, NST according to the present embodiment includes descriptioninformation of each fixed NRT service within one virtual channel. And,other side information can be included in a descriptor region.

A table_id field is an 8-bit unsigned integer number that indicates thetype of table section being defined in NST.

A section_syntax_indicator field (1-bit) shall be set to ‘0’ to alwaysindicate that this table is derived from the short form of the MPEG-2private section table.

A private_indicator field (1-bit) shall be set to ‘1’.

A section_length field (12-bit) specifies the number of remaining bytesthis table section immediately following this field. The value in thisfield shall not exceed 4093 (‘0xFFD’).

A table_id_extension field (16-bit) is table-dependent. It shall beconsidered to be logically part of the table_id field providing thescope for the remaining fields. Herein, the table_id_extension fieldincludes an NST_protocol_version field.

The NST_protocol_version is an 8-bit unsigned integer field whosefunction is to allow, in the future, this NRT Service Table to carryparameters that may be structured differently than those defined in thecurrent protocol. At present, the value for the NST_protocol_versionshall be zero. Non-zero values of NST_protocol_version may be used by afuture version of this standard to indicate structurally differenttables.

A version_number field (5-bit) represents a version number of the NST.

A current_next_indicator is a one-bit indicator, which when set to ‘1’shall indicate that the NRT Service Table sent is currently applicable.When the bit is set to ‘0’, it shall indicate that the table sent is notyet applicable and will be the next table to become valid. This standardimposes no requirement that next tables (those withcurrent_next_indicator set to ‘0’) must be sent. An update to thecurrently applicable table shall be signaled by incrementing theversion_number field.

A section_number field (8-bit) shall give the section number of this NRTService table section. The section_number of the first section in an NRTService table shall be ‘0x00’. The section_number shall be incrementedby 1 with each additional section in the NRT Service table.

A last_section_number field (8-bit) shall give the number of the lastsection (the section with the highest section_number) of the NRT Servicetable of which this section is a part.

A num_NRT_services field (8-bit) specifies the number of NRT services inthis NST section.

According to an embodiment of the present invention, an NST providesinformation for a plurality of fixed NRT services using a ‘for’ loop.Field information which is included in each fixed NRT service isexplained as follows.

An NRT_service_id is a 16-bit unsigned integer number that shalluniquely identify this NRT Service within the scope of this NRTBroadcast. The NRT_service_id of a service shall not change throughoutthe life of the service. To avoid confusion, it is recommended that if aservice is terminated, then the NRT_service_id for the service shouldnot be used for another service until after a suitable interval of timehas elapsed.

An NRT_service_status is a 2-bit enumerated field that shall identifythe status of this NRT Service. The most significant bit shall indicatewhether this NRT Service is active (when set to ‘1’) or inactive (whenset to ‘0’) and the least significant bit shall indicate whether thisNRT service is hidden (when set to ‘1’) or not (when set to ‘0’). Hiddenservices are normally used for proprietary applications, and ordinaryreceiving devices should ignore them.

A SP_indicator is a 1-bit field that shall indicate, when set, thatservice protection is applied to at least one of the components neededto provide a meaningful presentation of this NRT Service.

A short_NRT_service_name_length is a three-bit unsigned integer thatshall indicate the number of byte pairs in the short_NRT_service_namefield. This value is shown as ‘m’ in the No. of Bits column for theshort_NRT_service_name field. When there is no short name of this NRTservice, the value of this field shall be ‘0’.

A short_NRT_service_name field is a short name of the NRT Service. Whenthere is no short name of this NRT Service, this field shall be filledwith NULLs (‘0x00’).

An NRT_service_category is a 6-bit enumerated type field that shallidentify the type of service carried in this IP Service.

A num_components field (5-bit) specifies the number of IP streamcomponents in this NRT Service.

An IP_version_flag is a 1-bit indicator, which when set to ‘0’ shallindicate that source_IP_address, NRT_service_destination_IP_address, andcomponent_destination_IP_address fields are IPv4 addresses. The value of1 for this field is reserved for possible future indication thatsource_IP_address, NRT_service_destination_IP_address, andcomponent_destination_IP_address fields are for IPv6.

A source_IP_address_flag is a 1-bit Boolean flag that shall indicate,when set, that a source IP address value for this NRT Service is presentto indicate a source specific multicast.

An NRT_service_destination_IP_address_flag is a 1-bit Boolean flag thatindicates, when set to ‘1’, that an NRT_service_destination_IP_addressvalue is present, to serve as the default IP address for the componentsof this NRT Service.

A source_IP_address field shall be present if the source_IP_address_flagis set to ‘1’ and shall not be present if the source_IP_address_flag isset to ‘0’. If present, this field shall contain the source IP addressof all the IP datagrams carrying the components of this NRT Service. Theconditional use of the 128 bit-long address version of this field is tofacilitate possible use of IPv6 in the future, although use of IPv6 isnot currently defined.

An NRT_service_destination_IP_address field shall be present if theNRT_service_destination_IP_address_flag is set to ‘1’ and shall not bepresent if the NRT_service_destination_IP_address_flag is set to ‘0’. Ifthis NRT_service_destination_IP_address is not present, then thecomponent_destination_IP_address field shall be present for eachcomponent in the num_components loop. The conditional use of the 128bit-long address version of this field is to facilitate possible use ofIPv6 in the future, although use of IPv6 is not currently defined.

According to an embodiment of the present invention, the NST providesinformation for a plurality of components using a ‘for’ loop.

An essential_component_indicator is a one-bit indicator which, when setto ‘1’, shall indicate that this component is an essential component forthe NRT Service. Otherwise, this field indicates that this component isan optional component.

A port_num_count field shall indicate the number of destination UDPports associated with this UDP/IP stream component. The values of thedestination UDP port numbers shall start from thecomponent_destination_UDP_port_num field and shall be incremented byone.

A component_destination_IP_address_flag is a 1-bit Boolean flag thatshall indicate, when set to ‘1’, that thecomponent_destination_IP_address is present for this component.

A component_destination_IP_address field shall be present if thecomponent_destination_IP_address_flag is set to ‘1’ and shall not bepresent if the component_destination_IP_address_flag is set to ‘0’. Whenthis field is present, the destination address of the IP datagramscarrying this component of the NRT Service shall match the address inthis field. When this field is not present, the destination address ofthe IP datagrams carrying this component shall match the address in theNRT_service_destination_IP_address field. The conditional use of the 128bit-long address version of this field is to facilitate possible use ofIPv6 in the future, although use of IPv6 is not currently defined.

A component_destination_UDP_port_num is a 16-bit unsigned integer fieldthat represents the destination UDP port number for this UDP/IP streamcomponent.

A num_component_level_descriptors is a 16-bit unsigned integer field,that represents the number of descriptors providing additionalinformation for IP stream component, may be included.

A component_level_descriptors field includes one or more descriptorsproviding additional information for this IP stream component, may beincluded.

A num_NRT_service_level_descriptors field (4 bit) specifies the numberof NRT service level descriptors for this service.

An NRT_service_level_descriptor( ) field includes zero or moredescriptors providing additional information for this NRT Service, maybe included. This detailed service type can include a portal service forproviding web contents, Push VOD, A/V download or the like.

A num_virtual_channel_level_descriptors field (4-bit) specifies thenumber of virtual channel level descriptors for this virtual channel.

A virtual_channel_level_descriptor( ) includes zero or more descriptorsproviding additional information for the virtual channel which this NSTdescribes, may be included.

An NRT service is transferred via FLUTE and access information in an NSTtable is connected to FLUTE session information as follows. ASource_IP_address becomes a source IP address of a same server thattransmits all channels of FLUTE session.NRT_service_destination_IP_Address is signaled if there exists adestination IP address at a session level of this FLUTE session.

A component can be mapped to a channel within a FLUTE session and cansignal a separate destination IP address per channel (this is differentfrom an IP address signaled by a session unit) throughcomponent_destination_IP_address. Moreover, a destination port number issignaled through component_destination_UDP_port_num. And, it is able toadditionally designate the number of destination ports starting fromcomponent_destination_UDP_port_num through port_num_count.

By designating ports to a plural number, it is able to construct aplurality of channels for one destination IP address. In this case, onecomponent is able to designate a plurality of channels. Yet, it ispreferable that a channel is identified via a destination IP address ingeneral. In this case, one channel can be regarded as mapped to onecomponent.

Content items/files for an NRT service are transferred through FLUTE andcorresponding FLUTE session information is signaled using accessinformation in an NST table. FIG. 13 is an exemplary diagram for abit-stream syntax of NRT_component_descriptor( ) configured according toan embodiment of the present invention.

An NRT Component data means NRT content items or files delivered througha FLUTE session.

An NRT_component_descriptor( ) shall appear in the component descriptorloop of each component of each NRT service in the NST and all parametersin the descriptor shall correspond to the parameters in use for thatcomponent of the NRT service.

In the following description, each field information carried onNRT_component_descriptor shown in FIG. 13 is described.

A descriptor_length is a 8-bit unsigned integer that shall specify thelength (in byes) immediately following this field up to the end of thisdescriptor.

A component_type field (7-bit) shall identify the encoding format of thecomponent. The value may be any of the values assigned by IANA for thepayload_type of an RTP/AVP stream [10], or it may be any of the valuesin Table 3 in this disclosure, or it may be a “dynamic value” within therange of 96 to 127. For components consisting of media carried via RTP,the value of this field shall match the value in the payload_type fieldin the RTP header of the IP stream carrying this component.

Note that additional values of the component_type field within the rangeof 43 to 71 can be defined in future versions of this standard. The NRTservice stream transmitted through FLUTE protocol further requiresparameters further to signal a FLUTE session as a Table 3. In the Table3, ‘38’ of component_type being defined for FLUTE component in the ATSCor ‘43’ of component_type newly being defined for transmission NRT maybe used.

TABLE 3 component_type Meaning  0-34 Assigned or reserved by IANA,except that 20- 24, 27, and 29-30 are unassigned 35 H.264/AVC videostream component (assigned by ATSC use) 36 SVC enhancement layer streamcomponent (assigned by ATSC use) 37 HE AAC v2 audio stream component(assigned by ATSC use) 38 FLUTE file delivery session (assigned by ATSCuse) 39 STKM stream component (assigned by ATSC use) 40 LTKM streamcomponent (assigned by ATSC use) 41 OMA-RME DIMS stream component(assigned by ATSC use) 42 NTP timebase stream component (assigned byATSC use) 43-71 [Unassigned by IANA and reserved by ATSC use] 72-76Reserved by IANA 77-95 Unassigned by IANA  96-127 Designated by IANA fordynamic use

A num_STKM_streams is an 8-bit unsigned integer field that shallidentify the number of STKM streams associated with this component.

A STKM_stream_id is an 8-bit unsigned integer field that shall identifyan STKM stream where keys to decrypt this protected component can beobtained, by reference to the STKM_stream_id in the component descriptorfor the STKM stream.

An NRT_component_data (component_type) is explained as follow. TheNRT_component_data( ) element provides the encoding parameters and/orother parameters necessary for rendering this component. The structureof the NRT_component_data is determined by the value of component_typefield.

The FDT of the FLUTE sessions which is used to deliver the items listsall the content items and gives their sizes, data types, and otherinformation relevant to the acquisition of the items.

Therefore, the present invention obtains information for accessing aFLUTE session carrying a corresponding content using NST to receive acontent selected from a service guide constructed using NCT. And, thepresent invention intends to map information on a content item of NCT toinformation on a file transferred via a corresponding FLUTE session. Inthis case, identification of a service including the selected contentitem can be done via the NRT_service_id of the aforesaid NST. Yet, asmentioned in the foregoing description of FIG. 3, in order to know oneor more content items included in each NRT service and files belongingto the content items in further detail, mapping to a content identifierwithin FDT information on a FLUTE session is necessary rather thaninformation on the FLUTE session carrying the corresponding contentitem(s).

The NRT service is transferred via FLUTE and access information in anNST is connected to FLUTE session information as follows. ASource_IP_address becomes a source IP address of a same server thattransmits all channels of FLUTE session.NRT_service_destination_IP_Address is signaled if there exists adestination IP address at a session level of this FLUTE session.

A component can be mapped to a channel within a FLUTE session and cansignal a separate destination IP address per channel (this is differentfrom an IP address signaled by a session unit) throughcomponent_destination_IP_address. Moreover, a destination port number issignaled through component_destination_UDP_port_num. And, it is able toadditionally designate the number of destination ports starting fromcomponent_destination_UDP_port_num through port_num_count.

By designating ports to plural number, it is able to construct aplurality of channels for one destination IP address. In this case, onecomponent is able to designate a plurality of channels. Yet, it isrecommended that a channel is identified via a destination IP address ingeneral. In this case, one channel can be regarded as mapped to onecomponent.

In order to signal an additional attribute of a component constructing asession, it is able to use component_attribute_byte. Additionalparameters required for signaling a FLUTE session can be signaledthrough this field.

In order to signal the FLUTE session, parameters are necessary. Suchparameters include necessary parameters and parameters which areselectively necessary in association with the FLUTE session. First, thenecessary parameters include a “source IP address” parameter, a “numberof channels in the session” parameter, a “destination IP address andport number for each channel in the session” parameter, a “TransportSession Identifier (TSI) of the session” parameter and a “start time andend time of the session” parameter, and the parameters which areselectively necessary in association with the FLUTE session include an“FEC object transmission information” parameter, a “some informationthat tells a receiver in the first place, that the session containsfiles that are of interest”, and a “bandwidth specification” parameter.

The “number of channels in the session” parameter may be explicitlyprovided or may be obtained by summing the number of streams configuringthe session. Among the parameters, the “start time and end time of thesession” parameter, the “source IP address” parameter, the “destinationIP address and port number for each channel in the session” parameter,the “Transport Session Identifier (TSI) of the session” parameter andthe “number of channels in the session” parameter may be signaledthrough NST and component_descriptor.

FIG. 14 is an exemplary diagram for a bit-stream syntax of an FLUTEcomponent descriptor which is one of the NRT_FLUTE_component_dataconfigured according to an embodiment of the present invention.

A single NRT service may contain multiple FLUTE sessions. Each sessionmay be signaled using one or more FLUTE component descriptors, dependingon the IP addresses and ports used for the sessions.

In the following description, each field of NRT_FLUTE_component_data( )is explained in detail.

A TSI is a 16-bit unsigned integer field, which shall be the TransportSession Identifier (TSI) of the FLUTE session.

A session_start_time indicates the time at which the FLUTE sessionstarts. If the value of this field is set to all zero, then it shall beinterpreted to mean that the session has already started.

A session_end_time indicates the time at which the FLUTE session ends.If the value of this field is set to all zero, then it shall beinterpreted to mean that the session continues indefinitely.

A tias_bandwidth_indicator is a 1-bit field that flags the inclusion ofTransport Independent Application Specific (TIAS) bandwidth information.This bit shall be set to ‘1’ to indicate the TIAS bandwidth field ispresent, and it shall be set to ‘0’ to indicate the TIAS bandwidth fieldis absent.

An as_bandwidth_indicator is a 1-bit field that flags the inclusion ofApplication Specific (AS) bandwidth information. This bit shall be setto ‘1’ to indicate the AS bandwidth field is present, and it shall beset to ‘0’ to indicate the AS bandwidth field is absent.

A FEC_OTUndicator is a 1-bit indicator that indicates whether FEC ObjectTransmission Information is provided.

A tias_bandwidth field has a value. This value shall be oneone-thousandth of the TIAS maximum bandwidth, rounded up to the nexthighest integer if necessary.

An as_bandwidth has a value. This value shall be the AS maximumbandwidth.

A FEC_encoding_id field identifies a FEC encoding ID used in this FLUTEsession.

A FEC_instance_id field identifies a FEC instance ID used in this FLUTEsession.

By signaling the above described parameters, it is able to provide allinformation mandatory to receive a FLUTE session. And, it is able to usea method of receiving FDT via this session, obtaining information on allfiles carried on a FLUTE session via the received FDT and receivingtheses files.

This FLUTE component descriptor can be delivered viacomponent_level_descriptor loop of NST. In case that there is aplurality of FLUTE channels, such parameters at a session level as TSI,session_start_time, session_end_time and the like should be signaledonly once. Hence, one of components of several channels can transmit aFLUTE component descriptor via Component_level_descriptor loop.

In the following description, NCT is explained.

FIG. 15 is a diagram for a bit-stream syntax of an Non-Real-Time ContentTable (NCT) section configured according to an embodiment of the presentinvention.

In the following description, explained is NCT associated withsignaling/announcement of an NRT content.

In FIG. 15, an NCT is newly defined to signal NRT content. This is justone of various embodiments and other methods are considerable as well.Via NCT, it is able to signal an NRT content. Information of each fieldconstructing an NCT section is explained in detail as follows.

A table_id is an 8-bit field which shall be set to 0xTBD to identifythis table section as belonging to the NRT Content Table (NCT).

A service_id field is a 16-bit field which shall specify the service_idassociated with the NRT service offering content items described in thissection.

An NCT_version_number is a 5-bit field which shall indicate the versionnumber of this NCT instance, where NCT instance is defined as the set ofone or more NRT_content_table_section( ) having common values forservice_id, current_next_indicator, protocol_version, andtime_span_start. The version number shall be incremented by 1 modulo 32when any field in the NCT instance changes.

A current_next_indicator is a 1-bit indicator which shall always be setto ‘1’ for NCT sections; the NCT sent is always currently applicable.

A protocol_version is an 8-bit unsigned integer field which shall be setto zero. The function of protocol_version is to allow, in the future,this table type to carry parameters that may be structured differentlythan those defined in the current protocol. At present, the only validvalue for protocol_version is zero. Non-zero values of protocol_versionmay be used by a future version of this standard to indicatestructurally different tables.

A time_span_start is a 32-bit unsigned integer which shall represent thestart of the time span covered by this instance of the NCT, expressed asthe number of GPS seconds since 00:00:00 UTC, Jan. 6, 1980. The time ofday of time_span_start shall be aligned to minute 00 of the hour. Thevalue zero for time_span_start shall indicate the time period covered byhis NCT instance began in the indefinite past. The value of time_spanshall be the same for each section of a multi-sectioned NCT instance.The values of time_span_start and time_span_length shall be set suchthat the specified time span does not overlap with any other NCTinstance in this IP subnet.

A time_span_length is a 11-bit unsigned integer field in the range 0 to1440 which shall indicate the number of minutes, starting at the timeindicated by time_span_start, covered by this instance of the NCT. Onceestablished, the value of time_span_length for a given value oftime_span_start shall not change. A value of time_span_length of zeroshall mean this NCT instance covers all time starting at time_span_startinto the indefinite future. If the value of time_span_start is zero,time_span_length shall have no meaning. The value of time_span_lengthshall be the same for each section of a multi-sectioned NCT instance.The values of time_span_start and time_span length shall be set suchthat the specified time span does not overlap with any other NCTinstance in this IP subnet.

A num_items_in_section is a 8-bit unsigned integer field which shallindicate the number of content items described in this NCT section.

A content_linkage is a 16-bit unsigned integer field in the range 0x0001to 0xFFFF which shall specify the identification number of the contentdescribed. Value 0x0000 shall not be used. The content_linkage performstwo linkage functions: it links metadata in the NCT to one or more filesin the FLUTE FDT associated with this NRT service; it also forms theTF_id (identifier for Text Fragment in Text Fragment Table). The valueof the content_linkage field shall correspond to either the value of oneof the FDT-Content-Linkage elements or the value of one of theFile-Content-Linkage elements in the FLUTE FDT for each file associatedwith the content item. For a particular virtual channel, the value ofcontent_linkage shall uniquely identify each of the items of contentscheduled to be available for download.

An updates_available is a Boolean flag which shall specify, when set to‘1,’ that the referenced content item(s) will be updated periodically:for content items delivered in FLUTE sessions, receiving devices areexpected to monitor for changes the TOI associated with each fileassociated with the given value of content_linkage. When theupdates_available flag is set to ‘0’, updates are not expected to beprovided for the associated content item(s), and receivers are notexpected to look for them.

A TF_available is a Boolean flag which shall specify, when set to ‘1’that a Text Fragment is present in a Text Fragment Table in the servicesignaling channel. When the flag is set to ‘0,’ no Text Fragment isincluded in the service signaling channel for this content item.

A low_latency is a Boolean flag which shall specify, when set to ‘1,’that the content is available within the current digital transport witha low enough latency that its retrieval should be attempted while theuser waits. When the flag is set to ‘0,’ retrieval latency is longer andthe user interface should suggest to the user to return later forviewing.

A content_length_included is a Boolean flag which shall indicate, whenset to ‘1,’ that the content_length field is present in this iterationof the “for” loop. Setting this flag to ‘0’ shall indicate thecontent_length field is not present in this iteration of the “for” loop.

A playback_length_in_seconds is a 20-bit unsigned integer quantity whichshall specify the duration of playback of the content, in seconds. Forcontent consisting only of text and/or still images, the value zeroshall be used. For content that includes audio or audio/video content,the playback_length_in_seconds shall indicate the playback length of theaudio or audio/video content.

A content_length, when present, this 40-bit unsigned integer quantityshall represent the total size in bytes of the content item or items.This item is used by the receiving device to determine if enough memoryis available to store it before downloading is attempted. Thecontent_length field shall be present when content_length_included isset to ‘1’ and absent otherwise. When content_length is not present in agiven iteration of the “for” loop, the length of the content describedin that iteration shall be the value specified in thedefault_content_length field in the NRT_service_info_descriptorQ, ifpresent in the SMT.

A playback_delay_included is a Boolean flag which shall indicate, whenset to ‘1,’ that the playback_delay field is present in this iterationof the “for” loop. Setting this flag to ‘0’ shall indicate theplayback_delay field is not present in this iteration of the “for” loop.

A duration is a 12-bit unsigned integer field in the range 1 to 2880which shall specify the expected cycle time, in minutes, of the carouselcontaining the referenced content item. A receiver is expected to usethe duration parameter to determine the amount of time needed to capturethe referenced content.

A playback_delay is a 20-bit unsigned integer count of the number ofseconds following reception of the first byte of the associated contentthe receiver shall wait before playback may start, while buffering theincoming stream. A value of zero shall indicate playback may commenceimmediately. When playback_delay is not provided, the receiver isexpected to retrieve the complete file or files set prior to playback.

A expiration_included is a Boolean flag which shall indicate, when setto ‘1,’ that the expiration field is present in this iteration of the“for” loop. Setting this flag to ‘0’ shall indicate the expiration fieldis not present in this iteration of the “for” loop.

A expiration is a 32-bit unsigned integer which shall represent theexpiration time of the content, expressed as the number of GPS secondssince 00:00:00 UTC, Jan. 6, 1980. Following expiration, the contentshould be deleted from memory. If an expiration time is not specified,receivers are expected to use methods of their own choosing to managememory resources.

A content_name_length is a 8-bit unsigned integer field which shallspecify the length (in bytes) of the content_name_text( ).

A content_name_text( ) field which shall specify the content item titlein the format of a multiple string structure.

A content_descriptors_length is a 12-bit unsigned integer field whichshall indicate the total length (in bytes) of the content itemdescriptor list that follows.

A content_descriptor( ) is a one or more descriptors which may beincluded in the NCT in an iteration of the content item “for” loop.Table 4 lists some content-level descriptors usable in the NCT. Thepresence of some descriptors is mandatory. Required content-leveldescriptors shall be as indicated with the word “Required” in Table 4.

TABLE 4 Descrip- Descrip- tor Name tor Tag Reference and DescriptionTime slot TBD Sec. 9.8. Provides the time(s) the associated descriptorcontent is scheduled to be made available in the digital transport.Required. Media type TBD Sec. 9.5. Lists the Media types of thoseformats descriptor and encodings for which receiver support is essentialfor a meaningful presentation of the service. Internet TBD Sec. 9.9.Provides optional URLs for Internet- location based access to thecontent. descriptor ISO-639 0x0A ISO/IEC 13818-1 [4] Sec. 2.6.18. Ifpresent, language indicates the language of audio and/or textualdescriptor components of the service. Content 0x24 A/57 [6] and ISO/IEC13818-1 [4]Sec. labeling 2.6.56. Associates the content with contentdescriptor labeling metadata. Use of ISAN is strongly recommended forcontent containing audio/ video components. MPEG-2 0x2B ISO/IEC 13818-1[4] Sec. 2.6.68. Provides AAC audio information pertaining to the audioportion of descriptor the content. Caption 0x86 A/65 [1] Sec. 6.9.2.Provides caption service service information pertinent to the contentobject(s). descriptor Content 0x87 A/65 [1] Sec. 6.9.3. Provides contentadvisory advisory information pertinent to the content object(s).descriptor Genre 0xAB A/65[1], Sec. 6.9.13. Indicates the Genredescriptor category associated with the content object(s). ATSC 0xADA/53 Part 3 [5] Sec. 6.8.4. Usable for private private informationassociated with the content information object(s). descriptor M/H 0xBCA/153 Part 3 [3] Sec. 7.8.1. The following component component types areapplicable for NRT-IT descriptor use: component type Meaning 35H.264/AVC video stream 36 SVC enhancement layer stream 37 HE AAC v2audio stream 39 STKM stream component 40 LTKM stream component

A descriptors_length is a 10-bit unsigned integer number that indicatesthe number of bytes of descriptors (if any) to follow.

A descriptor( ) is a data structure in standard descriptor format (tag,length, data) that provides information about the NRT content describedin this NRT_content_table_section( ). No descriptors of this type arecurrently defined.

FIG. 16 is a flowchart for a method of configuring NRT guide informationand providing contents according to another embodiment of the presentinvention.

Referring to FIG. 16, a receiver checks an NRT service carried on avirtual channel [S1601] using PSI/PSIP (PMT, DST and VCT) informationand then accesses an NRT signaling channel transmitted via an IP layer[S1602].

Subsequently, NST is extracted from the accessed NRT signaling channel[S1603].

The receiver parses the extracted NST, connects the NRT service, andreceives and pre-stores the NRT contents transferred through the FLUTEsession and FDT information of the received NRT contents [S1604].

An NCT having NRT_service_id is extracted from the NRT signalingchannel.

NCT is received [S1605]. The receiver obtains detailed information ofNRT contents using each field in the received NCT [S1606]. The NRT guideinformation is constructed using the detailed information obtained inthe step [S1606] and is then displayed [S1607].

If a signal indicating that a specific NRT content has been selected bya user via the displayed NRT guide information is received [S1608], thereceiver identifies content identifier of the selected NRT content inthe NRT guide information and detects a content_id matched with thecontent identifier in the pre-stored FDT. And the receiver reproducescorresponding NRT content [S1609]. The embodiment of FIG. 16 shows thatfirstly a receiver accesses a FLUTE session and stores (or downloads)content items/files in the storage. After storing the contentitems/files in the storage, the receiver displays the NRT guideinformation if a user wants to view the NRT guide information. When auser selects a content item through the displayed NRT guide information,the receiver displays the selected content item by extracting theselected content item from the storage. This embodiment is performed ifa receiver has a sufficient storage space and some users want to receiveall NRT content items/files.

When matching operation between the content identifier of the selectedNRT content in the NRT guide information and content_id of the FDT isperformed, a NRT service which contains the NRT content (NRT contentitems/files) has to be identified. The NRT service is identified using aservice identifier field of the NCT and the NST. So if some content isselected in the NRT service guide information, a receiver identifiescontent identifier through the NCT and then detects a service identifierthrough the NCT and NST. So the receiver knows which service includingthe selected content is provided and displayed.

A signaling structure of the above described NRT service is shown inFIG. 17.

FIG. 17 is a diagram for an NRT service signaling structure configuredaccording to another embodiment of the present invention.

Referring to FIG. 17, each ATSC virtual channel includes NRT servicesignaling channel to be transferred as IP stream. At this time, the NSTand NCT are transferred via the NRT service signaling channel. The NSTincludes a table entry transferring corresponding NRT service. Forinstance, three NRT channels (NRT channels 0, 1 and 2) are provided onATSC Virtual Channel 0. In case of ATSC Virtual Channel 1, NRT channels3, 4 and 5 are provided. In particular, one virtual channel includes oneor more NRT channels. And, an NST is able to identify each of the NRTchannels. Each of the NRT channels carries an IP stream.

FIG. 18 is an exemplary diagram to explain a FDT schema for detecting afile having a content_id according to an embodiment of the presentinvention, and FIG. 19 is an exemplary diagram to explain a FDT schemaaccording to another embodiment of the present invention, whichrepresents a FDT instance level entry file designating method. An NRTcontent has a plurality files. But there is no indication in each file.It is difficult to find files belonging to the NRT content. So FIG. 18and FIG. 19 show that inserting content_id to a FDT for each files.

In the following description, a FDT instance level refers to a levelcontaining a portion, in which the common attribute is defined, if thecommon attribute of all files declared in the FDT needs to be defined. AFDT file level is used to indicate a level containing definition of theindividual attribute of each of the files.

The receiver identifies whether a transferred service via correspondingchannel is an NRT service based upon the PSI/PSIP, NST and NCT. Also,the receiver identifies content items and files of corresponding NRTservice.

As mentioned in the foregoing description, the receiver may identifyfiles and content items in the fixed NRT service. However, the receivercannot be matched with the files to the content items because of nothaving the information on the files in the content items. Accordingly,the receiver cannot process the received fixed NRT service.

Therefore, the present invention can provide a method for identifyingwhich files are associated with the content items. In other words, themethod will indicate what files exist in the content items. In thiscase, the receiver can properly process the received fixed NRT services.In this disclosure, the method may be specified based on the FDTinformation in the FLUTE session transmitting fixed NRT services. Forinstance, each file constructing the content items is identified basedon content-location and TOI field specified in the FLUTE session. Acontent_id in the FDT is matched with a content identifier of a contentin the NCT.

Referring to FIGS. 18 and 19, a part indicated by #1 declares content_idat FDT-Instance level. In this case, the declared content_id is given toall files declared within the corresponding FDT-Instance. By newlygiving content_id at a file level, it is able to override thisinformation. Alternatively, if a specific file belongs to anothercontent item instead of a content item defined at the FDT-Instancelevel, this can be announced by giving a file level content_id that willbe explained in the following description. In the present embodiment,content_id is represented using 32 bits.

A part indicated by #2 declares content_id at a file level. In thiscase, unlike #1 where it includes all files, #2 limits to filesassociated with content_id. If a file included within FDT Instancebelongs to a different content item, it is signaled that each filebelongs to a prescribed content item using this method. At the filelevel, it is possible to know where the file belongs within the contentitems and what the entry is on every file of the content.

A part indicated by #3 is a method for informing each file whether thecorresponding file is an entry file. In other words, it defines thecontent-id of the entry file. In particular, a file, which is playedback in the first place, or a file corresponding to a root file, whichshould be executed first to access a content item, among several filesconstructing a content item, is called an entry file. This partindicates a method of announcing this information. If it is omitted as‘false’, a basic value means that a corresponding file is not an entryfile. “Entry” refers to the header of a file that needs to process inorder to execute the file. For example, “index.html” can be an “entry.”Therefore, an entry file will be set to “true” and other files will beset to “false.” Through the entry file, redundancy in sending the samefiles can be effectively controlled. Once a file has been downloaded,the same file does not need to be downloaded in a different or aseparate instance because the entry file will indicate the file of thecontent for other references.

By signaling a presence or non-presence of an entry according to a groupbelonging at a file level, a specific file plays a role as an entry in aspecific group but may fail to play the role in another group.

As a method of announcing a presence or non-presence of an entry file incase of assigning content_id at FDT-instance level, the following twokinds of methods can be taken into consideration.

1) Method of assigning File-level content_id to a file corresponding toan entry file in addition and setting its entry attribute to ‘true’—inthis case, it is disadvantageous in that content identifier isoverlapped at FDT-Instance level and file level. Yet, this case canprovide the most flexible structure. In other words, it is possible toassign content_id to one of the File-level and FDT-instance level. Butif the different content_id is assigned to both File-level andFDT-instance level, a content_id of the File-level has a priority.

2) It is able to consider a method of directly referencing files playinga role as an entry file in the content identifier definition atFDT-instance level like another embodiment of the FDT scheme shown inFIG. 19. For this, in the embodiment shown in FIG. 19,FDT-Content-ID-Type is separately defined for FDT-instance level contentidentifier. This is extended to include a content location of an entryfile as indicated by #2. In case of #2, the entry level is defined byits content-id. For example, it defines what the entry file on eachcontent-id is.

In case of this method, it may be disadvantageous in that a contentlocation is repeatedly signaled. But, it becomes advantageous in thatentry file configuring information can be directly obtained per contentitem.

FIG. 20 is a flowchart to explain a process for processing an NRTservice in a receiver according to a different embodiment of the presentinvention.

Referring to FIG. 20, a receiver reads an NCT for signaling orannouncing an NRT service [S2001]. The receiver obtains information on acontent item constructing the NRT service via the read NCT [S2002]. Inthis case, the information on a content item, for example, may bedisplayed an NRT guide information which is constructed based on thecontent_id, content_name_text( ) and so on.

An NRT guide information is constructed based upon the obtainedinformation on the content item constructing the NRT service and is thendisplayed [S2003].

If at least one content is selected from the displayed NRT guideinformation by a user or the like [S2004], content_identifier for acorresponding content and service identifier associated with thecontent_identifier are obtained from the NCT for the selected content[S2005].

Using the service identifier of the NCT, the receiver reads an NSTincluding the same service identifier and then detects a FLUTE sessioninformation from the NST to receive the selected content [S2006]. Thenthe receiver accesses a FLUTE session for carrying a file constructingthe corresponding content item by finding service_id that matches theservice_id obtained in the step S2004 [S2007].

The receiver reads a FDT in the corresponding FLUTE session and thendetermined whether or not content identifier of the NCT is identical tothe content_id in the FDT.

If content_id of the FDT for the corresponding file is matched with thecontent_identifier of the NCT, the receiver receives a correspondingfile and then stores the received file [S2008].

In this case, the receiver can be aware of a file list belonging to eachcontent-item by parsing FDT instances within a session. The receiver isalso able to recognize which file in the file list plays a role as anentry. In particular, the receiver is able to know that each filebelongs to a prescribed content item using the FDT instance. Thereceiver is able to arrange a file list by a content item unitseparately and then stores the arranged list, if necessary.

When a specific content item starts to be used by a selection made by auser or the like, content consumption is initiated using the contentitem configuration information obtained in the above process and theentry information included in the content item configurationinformation.

In this case, in constructing a NRT guide information using the NCT, itis able to construct a NRT guide information using both NCT and NST byparsing them together instead of parsing NCT and NST in order or viceversa. For instance, after descriptors for NST and associated NRTservice have been parsed, application type and other requirementinformation are read by each NRT service unit. Moreover, application(service category) information on each service is displayed on an NRTguide information screen and detailed information is displayed usingother fields of NRT_service_info_descriptor (displaying a size of acorresponding service using storage_requirement field, displaying audioand video codec information using audio_codec_type field andvideo_codec_type field, etc.). It means that by parsing both NST and NCTthe receiver can display a lot of information on the NRT guideinformation.

Referring to FIG. 16, the NRT service may be provided by a PUSH methodor through an NRT service dedicated channel according to an embodimentof the present invention. At this time, the receiver receives thecontent items within the received NRT service through the accessed FLUTEsession and then stores. And, the receiver reproduces wanted contentitem within the stored content items based on the NCT. Herein, thewanted content item is selected by a user through the NRT guideinformation using the NCT.

However, referring to FIG. 20, the receiver parses an NCT and thenprovides an NRT guide information to a user based on the parsed NCT.And, if the user selects a specific content item, the receiver parses anNST. Then the receiver accesses an FLUTE session transmitting the NRTservice including the selected content item. The receiver receives theNRT service including the selected content item and then stores thecontent item. Finally, the receiver can reproduce the stored contentitem. So the selected content item is received and stored.

In the above-mentioned, the method of FIG. 16 differs from the method ofFIG. 20. The method of FIG. 16 can quickly reproduce the content item bypre-storing all content items of the NRT service. On the contrary, thereceiver can only store the wanted content item according to the methodof FIG. 20. Herein, the receiver can provide an NRT guide informationand then only receive the content item selected by the user.

It will be apparent to those skilled in the art that variousmodifications and variations can be made in the present inventionwithout departing from the spirit or scope of the inventions. Thus, itis intended that the present invention covers the modifications andvariations of this invention provided they come within the scope of theappended claims and their equivalents.

What is claimed is:
 1. A method of transmitting a non-real time (NRT)service, the method comprising: generating an NRT content table and anNRT service table, wherein the NRT service table contains service-levelattributes for a NRT service, wherein the NRT content table includesfirst information linking between the NRT content table and the NRTservice table, and second information identifying the content items andbeing used to map one or more NRT content items carried on a FileDelivery over Unidirectional Transport (FLUTE) file delivery session,wherein the NRT service table includes information identifying the NRTservice, the information being linked through the first information ofthe NRT service table; generating internet protocol (IP) datagrams, theIP datagrams including the NRT content items, the NRT content table andthe NRT service table, and transmitting the internet protocol (IP)datagrams.
 2. The method of claim 1, wherein the NRT service tablefurther includes category information indicating that a service is thenon-real time (NRT) service.